home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Chip 1996 April
/
CHIP 1996 aprilis (CD06).zip
/
CHIP_CD06.ISO
/
hypertxt.arj
/
9301
/
STCKR300.CD
< prev
next >
Wrap
Text File
|
1995-04-18
|
33KB
|
532 lines
@VSzebb és sokoldalúbb@N
@VStacker 3.00 for Windows and DOS@N
Egyre népszerûbbek a röptömörítôk. Gyermekbetegségeikbôl
rég kigyógyultak, s legelterjedtebb képviselôjük, a Stacker
a DOS után a Windowst is célba vette.
Nemrég jutott el hozzánk a Stacker harmadik verziója. Most
már @KStacker for Windows and DOS@N a neve a kaliforniai
Carlsbadban székelô Stac Electronics cég
szoftvertermékének.
Telepítéskor személyre szólóvá teszi (perszonalizálja) a
telepítô lemezeken lévô file-okat. Ez segíti a
kalózmásolatok eredetének kiderítését.
A Stacker 3.00 legfontosabb újdonságai:
@V*@N Az eddigi, DOS alatti segédprogramjait
továbbfejlesztették, s megjelent ezek Windows-változata is.
@V*@N A Stacker által kezelt ""virtuális" lemezmeghajtók
(ahol tömörítve tárolja a file-okat) jelszavas védelemmel
láthatók el. Ráadásul kétféle jelszó is megadható: az egyik
ismeretében ugyan olvashatók a file-ok, de nem írhatók
felül és nem törölhetôk (""read-only password"), a másik
ismeretében pedig szabadon dolgozhatunk a virtuális
lemezeken.
@V*@N Az eddigi 4 és 8 Kbyte-os clusterméret mellett
megjelent a 16 és 32 Kbyte-os is. Utóbbiak a nagy méretû --
például grafikus file-okat, képeket és hangfile-okat
tartalmazó -- lemezeken a Stacker mûködését gyorsítják, és
némileg tovább javítják a tömörítési arányát.
@V*@N Kilenc fokozatból (/P=1, ..., /P=9) választhatjuk ki,
hogy mennyire fontosnak ítéljük a tömörítés--kibontás
(tehát általában a lemezkezelés) sebességét és a tömörítési
arányt: a 9-es fokozatban tömörít a legjobban, de egyben
itt a leglassabb is, s értelemszerûen: az 1-es fokozatban
a legfürgébb, viszont nem a legtökéletesebb a tömörítés. A
kezdeti beállítás bármikor módosítható (de csak a DOS
újraindítása után lép életbe).
@V*@N A Norton SpeedDiskhez hasonló töredékmentesítô
(defragmentáló) programja, a SDEFRAG.EXE is többféleképp
mûködhet: például kérhetjük tôle az 1-es fokozatban
használt, ezért kissé ""laza" lemeztartalom 9-es fokozatú,
maximális újratömörítését is a lemez rendezése mellett.
Kijavították a korábbi SDEFRAG hibáját, tudniillik rendezés
és maximális újratömörítés esetén eddig csökkent (!) a
virtuális meghajtón szabadon maradt hely, ami elég
kellemetlen mellékhatás volt...
@V*@N A PREVIEW.EXE nevû segédprogrammal tömörítetlen
meghajtókat vizsgálhatunk. Megadja, hogy milyen tömörítési
arányt lesz képes elérni a Stacker, ha ""ráeresztjük" a
meghajtóra.
@V*@N A virtuális Stacker meghajtókat hordozó DOS meghajtók
méretén belül szabadon növelhetô--csökkenthetô a virtuális
meghajtók mérete. Teljes eltávolítás (uninstall) is
kérhetô, s ezt intelligensen hajtja végre az UNSCREAT.EXE:
ha nincs elég hely a tömörített file-ok számára a hordozó
meghajtón, akkor ezt jelzi, s el sem indul. Ha megszakad a
futása (például hálózatkimaradás miatt), akkor
újraindítható; s ha sikeresen lefutott, akkor visszakapjuk
a virtuális lemez tartalmát, de immár a virtuális lemezt
hordozó DOS meghajtón.
@V*@N Mejelent a @KStacker Toolbox@N-nak elkeresztelt
STAC.COM nevû program. Ez menüs-helpes keretrendszer a
Stacker segédprogramjaihoz, így könnyebb azokat használni.
@V*@N Tovább javították a programok hibatûrését és
alkalmazkodó képességét a különféle helyzetekhez -- a
Stacker ""intelligensebbé" vált.
@VTapasztalatok@N
Két gépen próbáltuk ki a Stacker legfrissebb verzióját. Az
egyik a legutóbbi 386SX tesztünkben részt vett Albacomp
tendergép volt. Mivel a merevlemezén alig volt valami (MS
DOS 5.0, Windows), ezért a Stacker gyorsan felköltözött rá.
Feltûnt, hogy a telepítô program és a Stacker Toolbox egyes
képernyôi csak felvillannak, majd eltûnnek. Ezek közbülsô,
információs jellegû ablakok voltak, nem vártak választ, s
az elôzô, gombnyomást váró ablaknál megnyomott billentyû
ezeken is áthajtotta a programot.
Kipróbáltuk a @KP=1@N és a @KP=9@N beállítást. A P=1
érezhetôen gyorsabb mûködést eredményezett, de csak
leheletnyit. Egy gyors összehasonlítás viszont azt mutatta,
hogy mintegy 5 Mbyte-nyi file-on a lazább, P=1 beállítás
1,8:1 arányú, míg a P=9 csak 1,9:1 arányú tömörítést
eredményezett. (Az arányok a Stacker által mutatott, egy
tizedesjegynyi pontosságú értékek.)
A P=2..8 beállításokkal ezek után már nem is
kísérleteztünk. Látszik, hogy itt a Stacker fô tömörítô
algoritmusának árnyalatnyi módosításairól lehet csak szó.
Hogy kinek-kinek melyik beállítás rokonszenves, döntse el
maga. A legjobbnak talán a P=1 tûnik, az ezzel járó
idônkénti lemez-újratömörítéssel és lemezrendezéssel
(SDEFRAG).
Második alkalommal egy szerkesztôségi, 33 MHz-es 386-os
gépen telepítettük a Stacker 3.00-t (azóta is fent van
rajta, további tapasztalatok szerzése céljából). A 300
Mbyte-os, 90%-ig telített merevlemezre több óra alatt
""mászott fel". Apró bibi: az egyik telepítési mûvelet
közben közölte, hogy törli az üres könyvtárakat
(""kioptimálta" ôket, noha az ilyen könyvtárak többnyire
csak látszólag feleslegesek...). Egy 40 Mbyte-os, már
tömörített (ARJ) file-t nem tudott átrakni az általa
tömörített részbe, mert nem fért el ott. A telepítés végén
hiba nélküli lefutást jelzett (""no errors"), az elsô
DOS-beli @KCHKDSK /F@N parancs viszont rátalált az át nem
vitt, 40 Mbyte-os file könyvtári bejegyzésére, s 0
byte-osra javította azt. A file persze megvolt eredeti
helyén, a Stacker virtuális meghajtóját hordozó meghajtón,
így kisebb ijedtség után kijelenthettük: minden rendben --
s ez az azóta eltelt idôszakra is igaz maradt.
A Stacker 3.00 részletes, jól áttekinthetô jelentést tud
adni az általa tömörített virtuális lemezekrôl, megadva a
tömörítési arányt a lemez egészére, a file-okra
kiterjesztés (.EXE, .COM stb.) szerint csoportosítva,
illetve az egyes file-okra külön-külön is -- a
felsorolásokat tömörítési arány, kiterjesztés stb. szerint
rendezve kérhetjük egy (elôre-hátra lapozható tartalmú)
ablakba. Látványos és kényelmesen használható újdonság.
Nos, ez a program a nagy merevlemezen (nyilván a sok file
miatt) meghívva osztási hibával elszáll, s ilyenkor újra
kell indítani a gépet.
Már a Stacker 2.00 verziójával is lehetett röptömöríteni
floppykat. Az eredmény csigalassú floppymûködés volt,
minimális tömörítés mellett (2,0:1 arányban röptömöríthetô
file-oknál 1,1..1,2:1 arány). A 3.00 verziónál a
floppysebesség valamelyest javult, a tömörítési arány
változatlan, újdonság viszont a @KStacker Anywhere@N
elnevezésû kiegészítés. Ezt egy STACKER.EXE file testesíti
meg, amit a röptömörített floppy gyökérkönyvtárába rak a
Stacker, negyvenegynéhány Kbyte-os, s bármely más gépen
elindítható. îgy a röptömörített floppyk átvihetôk a gépek
közt, tekintet nélkül arra, hogy fut-e rajtuk a Stacker.
(Mellesleg: ezt a megoldást is a SuperStortól lesték el,
mint oly sok másikat -- persze ez lényegtelen). Lassúsága
és a minimális tömörítés miatt továbbra sem ajánljuk a
floppyk tömörítését.
Eddig ennyi derült ki a legújabb Stackerrôl. Komolyabb
fejlesztésnek csak a jelszavas védelem és a virtuális
meghajtók szabadon változtatható mérete illetve tartalmuk
megôrzése melletti megszüntethetôségük nevezhetô. A
Stacker 3.00 nevében a @Kfor Windows@N kitétel enyhe
túlzás: a karbantartási mûveletek sem Windows, sem
Desqview alatt nem indíthatók el -- ami helyes, mert
multitaszkos környezetben meglehetôsen kockázatos minden
ilyesmi... Bosszantó viszont, hogy mindeközben a szabad
lemezterület növelésére hivatott programcsomag mérete több
mint háromszorosára, jó másfél Mbyte-ra hízott. A szépség
(ablakozás, Windows alatti csicsák) ennyit nem ér meg,
fôleg egy rendszerprogramnál...
A röptömörítô technológia tehát egy helyben topog. Tudjuk,
hogy rettentôen nehéz volt kifejleszteni magát a
röptömörítést (ráadásul úgy, hogy a háttérben, abszolút
biztonságosan, és lehetôleg gyorsan fusson a
tömörítés--kibontás) -- nem véletlenül váratott magára
sokáig. S érezhetô, hogy mindaz, amit itt felsorolunk,
közel ugyanilyen nehézségeket okozhat esetleg, ám sokkal
több értelmük lenne, mint az -- angolból vett kifejezéssel
-- csingi-lingiknek. Tehát, a vágyaink:
@V*@N Ki-be kapcsolható tömörítés -- ha úgy tetszik, a P=0
lehetôsége. îgy (sebességmérési táblázatunkból látszik) a
röptömörítés fô hátránya, a nyers adatátvitel lassúsága
eltûnhetne, vagy legalább enyhülne.
@V*@N Töredékmentesítés a háttérben
(röp-töredékmentesítés). Nem valamiféle erôszakos, ""túl
okos" megoldás hiányzik, hanem az, hogy a nyilvánvaló
üresjáratokat -- amikor például a DOS promptnál villog a
kurzor a magárahagyott gép képernyôjén -- valami hasznos
célra kihasználja az operációs rendszer vagy más program.
Ha ez a ""más program" a Stacker, akkor a legkézenfekvôbb,
leghasznosabb tevékenység ez a ""láthatatlan SDEFRAG"
lehetne.
@V*@N A tömörítési arány további fokozása. Jelenleg a
röptömörítôk a Liv-Zempel féle tömörítés LZS-féle
módosítását használják ilyen-olyan formában. Ez tûrhetô
hatásfokú, ugyanakkor rettentô gyors -- ami nagyon fontos!
-- a jobban tömörítô módszerekhez képest. Az off-line
(tehát kizárólagos mûködésû) újratömörítés alatt
(Stackerbeli példa: @KSDEFRAG /P=9@N) viszont kevésbé
fontos a gyorsaság. Ráadásul (mint a hagyományos
tömörítôknél, a PKZIP-nél és az ARJ-nél jól látszik) a
kibontás (""visszatömörítés") ideje a file-ok tömörített
méretével arányos, így a késôbbi, on-line röpmûködés során
a kibontás még gyorsulna is...
@V*@N A file-használat folyamatos figyelése. A soha nem
használt (soha meg nem nyitott) file-ok (ilyen a file-ok
túlnyomó többsége!) lementésére, törlésére stb. ez alapján
javaslatot tehetne a röptömörítô, s ugyanígy javasolhatná a
néhány leggyakrabban használt file memórialemezre
(RAM-diszk, RAM-drive, lásd méréseinket) rakását.
Talán majd a Stacker 4.00-ban találkozunk ezek
valamelyikével... Sebességmérési eredményeink és elemzésük
keretes cikkeinkben olvashatók. Lapzártakor a vezetô
röptömörítôk (SuperStor, Stacker) 286-os és 386SX gépeken
való sebességét, illetve tömörítési arányukat vizsgáljuk.
Meglepetés nem várható. Eddigi, több mint egy évig tartó
használatuk során már kiderült, hogy a SuperStor sokkal
gyorsabb (minden géptípuson), és nagyjából ugyanannyira
tömörít. A tömörítésük közti eltérés kisebb mint 5%, s
általában is elmondható, hogy bármely röptömörítô
használatakor mintegy kétszer annyi (tömörítetlen) file fér
a merevlemezekre, mint csupasz DOS alatt.
@KBérces László@N
@VMS DOS 6.0 -- DoubleDisk@N
Nemrég bemutattuk az MS DOS 6.0 béta változatát, amelybe
már beépítették a DoubleDisk röptömörítô program 3.00
verzióját. Októberi számunk DR DOS cikkében (54. oldal)
közöltünk egy mérési táblázatot, amelyben többek között
megmértük néhány röptömörítô sebességét is (MS DOS 5.0
alatt).
E táblázatot most kiegészítjük a DoubleDisk 3.00 adataival.
A mérések körülményeirôl októberi cikkünkben olvashatnak
részletesen, most csak a legfontosabbakat foglaljuk össze.
A teszteknél egy Giga-Byte típusú, 33 MHz-es 486-os gépet
használtunk, 120 Mbyte-os merevlemezzel, 4 Mbyte
memóriával. Az Eurotesztben használt CONFIG.SYS-ben
BUFFERS=48, DOS=HIGH módosításokat tettük.
A táblázatban most csak a DOS, a (leggyorsabbnak bizonyult)
SuperStor 1.07 és a DoubleDisk 3.00 alatti mérési
eredményeket adjuk meg. A Stacker 2.00 és az XtraDrive 1.0
eredményeit októberi számunkban találhatják meg az
érdeklôdôk. A mérési adatokból csak a legfontosabbakat, az
alkalmazási tesztek futási idôit hagytuk meg.
DOS SuperStor 1.07 DoubleDisk 3.00
Szabad DOS memória (byte) @V*1@N: 634000 589440 590224
@VProgramok futási ideje (s)@N
Turbo Pascal 5.5-teszt 54,43 49,70 64,81
dBase III Plus-teszt 146,98 178,72 259,90
DOS-teszt 64,64 57,56 77,88
Lotus 1--2--3-teszt 98,81 99,96 100,12
Windows 3.0-teszt 34,54 33,83 33,89
Word 5.5-teszt 61,02 62,94 65,85
A számokból jól látszik a DoubleDisk lassúsága (pedig a
mellékelt szöveges file-ban azt írták, hogy sokat
javítottak a sebességén -- hmmm...). Megkönnyíti az
áttekintést, ha megnézzük az összesített futásidôket (más
mérésekkel persze más arányok jönnének ki -- a lemezigényes
alkalmazásokra például az elsô három sor adatai jellemzôk):
DOS 460,42 másodperc (100%), SuperStor 482,71 s (104,8%),
DoubleDisk 602,45 s (130,8%). Memóriaigénye a szokásos
42--44 ezer byte körüli, egyetlen szembetûnô képessége a
virtuális meghajtók szabad átméretezése. Erre azonban
konkurensei is képesek már (igaz, nem régóta), így
kíváncsiak vagyunk, mivel próbálják lefôzni
versenytársaikat?! Csak reméljük, hogy nem fogják a
Microsoft új, aggresszív stílusát követve a MS DOS 6.0-val
inkompatiblissé ""varázsolni" a többi röptömörítôt...
@VSebesség@N
Nagyon kíváncsiak voltunk az új Stacker sebességére.
Kezelési kényelmével, szolgáltatásaival eddig sem volt
ellenszenves, de a korábbi verziók, az 1.00, 1.10 és a 2.00
érezhetôen visszafogták a lemezmûveletek sebességét,
különösen az írási mûveletekét. Kézikönyve (mint minden
röptömörítôé) ezért is javasolja, hogy a Windows ""átmeneti
cserefile"-ját (temporary swapfile) tömörítetlen (DOS)
meghajtóra rakjuk. Októberi táblázatunkból azonban
kiderül, hogy (az 1.10 verzióhoz képest sokkal fürgébb)
2.00 verzió más programokat is fékez.
A méréseket 50 MHz-es Kventa 486SX gépen végeztük (81
Mbyte-os merevlemez, 4 Mbyte memória). Az eredmények
mindenütt másodpercben értendôk, tehát a kisebb számok
jelzik a jobb eredményeket.
RAMDRIVE DOS DOS SuperStor 1.07 SuperStor 1.07 Stacker 2.00 Stacker 2.00 Stacker 3.00 Stacker 3.00 Stacker 3.00 Stacker 3.00
(cache) (cache) (cache) (P=1) (P=1, cache) (P=9) (P=9, cache)
Compiler 15,16 56,80 24,83 64,42 23,29 61,57 25,32 57,23 25,43 62,67 31,26
dBase 19,60 131,60 17,63 171,80 38,99 -- -- -- -- -- --
DOS 12,02 63,16 30,97 82,00 31,36 86,83 34,71 79,20 33,72 76,62 38,72
ARJ 32,24 64,16 55,14 75,69 51,14 85,96 55,42 82,67 63,38 86,13 59,15
30 Mbyte írása 3,45 52,62 100,78 171,75 151,70 211,91 176,58 210,53 208,49 228,21 216,41
30 Mbyte olvasása 3,11 46,31 91,62 93,65 94,14 89,74 96,01 90,35 117,38 90,57 119,24
@VÖsszesen:@N
dBase nélkül
(%, DOS=100%) 23 100 107 172 124 189 137 184 158 192 164
dBase-zel
(%, DOS=100%) 21 100 77 159 94 -- -- -- -- -- --
Méréseinkrôl néhány szót. A ""compiler" tesztben mindig a
Turbo Pascal 5.0-val fordítjuk le ugyanazt a viszonylag
nagy, több file-ból álló programot (75 Kbyte-os .EXE-vé). a
dBase tesztben tipikus adatbázis-mûveleteket futtatunk. A
DOS teszt tipikus file-mûveletekbôl áll, ám hiányzik belôle
a nagyobb adatmennyiségek írása-olvasása. Ezek azok a
tesztek, amelyek a szabványos Eurotesztbôl leginkább jelzik
a lemezmûveletek sebességét. (Lásd még októberi cikkünket,
ott teljes adatsort mértünk.)
Ezt kiegészítettük az MS DOS 5.0 összes file-jának ARJ-vel
való betömörítésével és a tömörített file ellenôrzésével
(@KARJ a /jt1@N), valamint 30 Mbyte-nyi, tömöríthetetlen
adat lemezreírásával és visszaolvasásával (64 Kbyte-os
pufferen át). Ez utóbbi mérés az adatátviteli sebességre
jellemzô adatot szolgáltat, mellesleg kitûnôen jelzi, hogy
mennyit foglalkozik egy-egy (röp)tömörítô a tömörítendô
adatok, file-ok préselésével.
A mérések során állandóan bekapcsolva hagytuk a QEMM
memóriakezelôt, @KRAM@N állásban. @KDOS=HIGH@N beállítás
mellett így 610 Kbyte szabad memória maradt a SuperStor
1.07, s 631 Kbyte a Stacker 3.00 használata esetén. Ahol a
HyperDisk lemezgyorsító (cache) program 4.31 shareware
változatát használtuk, ott ""(cache)" megjegyzéssel
jeleztük ezt. A cache célú memória ekkor 1024 Kbyte volt.
Az Euroteszten kívüli méréseket a memórialemezen (RAMDRIVE)
csak több részre bontva tudtuk elvégezni, de ez nem
befolyásolja az eredmények jelentését.
A dBase teszt most sem futott le a Stacker alatt -- sajnos
a 3.00 verzió sem javították ki. A QEMM az ismételt
próbálkozások egyike alkalmával ki is írta a lefagyás okát:
érvénytelen utasításkód. Mivel ez már a harmadik gép, ahol
ezt tapasztaltuk, egyértelmûen a Stacker a hibás, és egy
korábbi cikkünk Stackertôl átvett megjegyzése is
megkérdôjelezhetô, miszerint egy korai ALR BusinessVEISA
alaplap lenne a vétkes abban, hogy nem fut rajta a
Stacker...
A mérések kiértékelése minket is meghökkentett. A DOS
alatti dBase mérést ismételten elvégeztük, hibára
gyanakodva. A merevlemez LED-jét figyelve látszott, hogy a
dBase minden mûveletet a HyperDisk által kezelt cache-ben
végez, ennek tudható be a hihetetlen sebesség. Hogy a DOS
RAMDRIVE programjával létrehozott memórialemez miért volt
lassabb a cache-elt DOS-nál? Talán a HyperDisk okosabb a
RAMDRIVE.SYS-nél... Nem tudjuk.
Feltûnô még a nyers adatátviteli mérések eredménye. DOS
alatt a cache ilyenkor csak lassít, mert többször kell
átrakosgatni a memóriában az adatokat. A FAT-kezelés
viszont ilyenkor is gyorsul, ez is látszik a kissé
ellentmondó adatok részletes elemzésekor. Ennek a mérésnek
a kivételével mindenütt jótékony hatású a cache. Látszik,
hogy a Stacker új verziója nem lett gyorsabb, s nagyon
feltûnô, hogy nagy adatmennyiségek átvitelénél mennyire
lassú minden röptömörítô, még a SuperStor is. Ezért a
Windows cserefile-jaihoz, kép- és hangfile-ok (multimédia)
kezelésére, adatbázisokhoz röptömörített (virtuális)
lemezeket ugyan lehet használni (még Stackert is), de
többnyire nem érdemes. Ha van elég memória, akkor azt
ilyenkor használjuk memórialemezként, illetve a Windows
esetén hagyjuk meg azt memóriának. Az eredmények további,
részletekbe menô elemzését az Olvasókra hagyjuk.
@VSuperStor -- hogyan használjuk?@N
Néhány megjegyzéssel segítenénk azokat, akik a Stacker
riválisát, a SuperStort is ki szeretnék próbálni. A DR
DOS-beli SuperStorok eredeti környezetükben, a DR DOS alatt
kifogástalanul mûködnek. Azokon a gépeken, ahol van felsô
(upper) memóriaterület, a HIDEVICE paranccsal elérhetjük,
hogy csak mintegy 20 Kbyte-ot foglaljon le az alsó 640
Kbyte-ból.
A SuperStor DR DOS 6.0-ból kibányászható verziója csak DR
6.0 alatt használható -- MS DOS 5.0 alatt tapasztalható
hibájáról már írtunk, életveszélyes! A DR DOS 6.01 mellé
adott verzió korrektül mûködik MS DOS 5.0 alatt is, még a
Windows 3.1-gyel sincs problémája (naná, hiszen ezért
jelentette meg a Novell a DR 6.01 verzióját ""6.0 update"
elnevezéssel). Viszont MS DOS 5.0 alatt nem lehet
visszahozni a SuperStor által kezelt virtuális meghajtókon
a törölt file-okat a szokásos módon, például a Norton
Unerase-zel, Quick Unerase-zel.
Aki MS DOS 5.0-t és SuperStort akar használni egyszerre,
annak számolnia kell ezzel a bakival. És azzal is, hogy MS
DOS 5.0 alatt a DR 6.01-beli SuperStor meghajtóprogramja
nem tölthetô fel a felsô memóriaterületre, csak ha a QEMM
386 memóriakezelôt használatuk. (Más memóriakezelôkkel nem
próbálkoztunk -- a QEMM alatt viszont automatikusan
felrakja a felsô memóriába önmagának mintegy a felét, s
csak 23|696 byte marad az alsó 640 K-ban, miként DR DOS
alatt.) Hosszas használata alatt nem tapasztaltunk más
problémát. Az, hogy a SuperStor virtuális meghajtóin csak
legfeljebb 256 file lehet egy-egy könyvtárban, rémhír.
Nekünk voltak s vannak olyan könyvtáraink, amikben több
mint 1000 file van (ráadásul MS DOS 5.0 alatti SuperStor
meghajtókon), s -- lekopogjuk -- gond egy szál se.
A fentiekhez kapcsolódik egy általános jótanács. Az
operációs rendszerekhez adott meghajtóprogramokat mindig
kockázatos más környezetben használni. Ha valaki mégis
próbálkozik ilyesmivel, elôször próbálja ki
""határhelyzetekben" az átoperált részt. A röptömörítôknél
(ilyen a SuperStor, s ilyen lesz az MS DOS 5.0 alatti
DoubleDisk is), lemezgyorsító (cache) programoknál ez
intenzív lemezhasználatot, a lemez csordultig írását, a gép
lemezmûveletek közbeni kikapcsolását, ""kényes" programok
(Windows 3.1 stb.) futtatását és hasonló helyzetek
kipróbálását jelenti. Ha minden rendben, akkor is érdemes
óvatosnak lenni az elsô napokban.
Legfrissebb hírünk: megjelent a SuperStor 2.0
továbbfejlesztett változata, SuperStor Pro néven. Nekünk a
SuperStornak eddig csak a DR DOS 6.0, 6.01 mellé adott
(licencelt), régi változatai voltak meg (v1.03, v1.07), s
nagyon jó tapasztalatokat szereztünk velük (a Stackernek
csak a reklámja és ismertsége jobb, teljesítménye gyengébb
nála). Kíváncsian várjuk, mit hoz a két vezetô röptömörítô
legújabb verzióinak összecsapása.
Stacker for Windows and DOS SETUP
░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░
░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░
░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░
░░░░╔═══════════════════════════ Tune Stacker ════════════════════════════╗░░░░
░░░░║ ║░░░░
░░░░║ Stacker can maximize either the speed or the amount of ║░░░░
░░░░║ compression. ║░░░░
░░░░║ ║░░░░
░░░░║ You can change this setting after Setup by using Stacker ║░░░░
░░░░║ Tuner from Stacker Toolbox. ║░░░░
░░░░║ ║░░░░
░░░░║ Speed/Space Balance:──────────────────────────────────────┐ ║░░░░
░░░░║ │ (») More Speed │ Fastest speed and standard compression │ ║░░░░
░░░░║ │ ( ) Balanced │ More compression and a bit less speed │ ║░░░░
░░░░║ │ ( ) More Space │ Best compression │ ║░░░░
░░░░║ └─────────────────────────────────────────────────────────┘ ║░░░░
░░░░║ ║░░░░
░░░░║ Continue ▄ Help ▄ Exit ▄ ║░░░░
░░░░║ ▀▀▀▀▀▀▀▀▀▀ ▀▀▀▀▀▀ ▀▀▀▀▀▀ ║░░░░
░░░░╚═════════════════════════════════════════════════════════════════════╝░░░░
░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░
░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░
░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░
Press F1 for Help
Bár viszonylag szûk határok közt, de bármikor
módosítható a sebesség/tömörség arány
Stacker for Windows and DOS Stacker Toolbox
░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░
░░░╔══════════════════════════ Stacker Toolbox ═══════════════════════════╗░░
░░░║ ║░░
░░░║ ══════ Stack ══════════ ┌──────── Configure...Passwords ─────────┐ ║░░
░░░║ Hard Disk │Stacker lets you use passwords with │ ║░░
░░░║ Floppy (removable) │stacked disks. With this tool, you can │ ║░░
░░░║ Unstack │assign a password to: │ ║░░
░░░║ │ │ ║░░
░░░║ ══════ Check ══════════ │ - Allow read/write access │ ║░░
░░░║ Drive Integrity │ │ ║░░
░░░║ Compression Report │ - Allow read-only access │ ║░░
░░░║ │ │ ║░░
░░░║ ══════ Optimize ═══════ │You can also: │ ║░░
░░░║ Stacker Optimizer │ │ ║░░
░░░║ Stacker Tuner │ - Change an existing password │ ║░░
░░░║ │ │ ║░░
░░░║ ══════ Configure ══════ │ - Remove a Stacker password │ ║░░
░░░║ Stacker Drive Size │ │ ║░░
░░░║ Expected Compression │After you press Enter, choose the │ ║░░
░░░║ » Passwords │Stacker drive. │ ║░░
░░░║ └────────────────────────────────────────┘ ║░░
░░░╚════════════════════════════════════════════════════════════════════════╝░░
░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░
F1 for help. Arrows () to select. F10 to exit.
A két fokozatú jelszavas védelem nagyon hasznos
újdonság
Stacker for Windows and DOS Report
░░┌──────────────────────────────── Actions ─────────────────────────────────┐░
░░│ Show Files Show Summary Change Drive │░
░░└──────────────────────────────────────────────────────────────────────────┘░
░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░
┌─ Sort By ──┐░╔═══════════════ File Information for Drive C: ═══════════════╗░
│ │░║ File File D:\STACVOL.DSK % of Compression ║░
│»Extension │░║ Extension Count Disk Usage Total Ratio ║░
│ │░║ ─────────────────────────────────────────────────────────── ║░
│ File Count │░║ EXE 198 8,517,120 8.37% 1.6:1 ║░
│ │░║ COM 57 632,320 0.62% 1.9:1 ║░
│ Disk Usage │░║ HLP 53 2,082,816 2.05% 1.8:1 ║░
│ │░║ CFG 39 26,112 0.03% 13.5:1 ║░
│ Comp Ratio │░║ TXT 33 82,944 0.08% 4.3:1 ║░
│ │░║ PCX 32 238,592 0.23% 4.5:1 ║░
└────────────┘░║ SYS 27 259,072 0.25% 2.2:1 ║░
░░░░░░░░░░░░░░░║ DLL 26 695,296 0.68% 2.3:1 ║░
┌─Sort Order─┐░║ GX2 19 146,432 0.14% 2.0:1 ║░
│ │░║ BMP 19 55,808 0.05% 5.0:1 ║░
│+ Ascending │░║ FON 16 143,360 0.14% 2.8:1 ║░
│ │░║ INI 15 18,944 0.02% 8.2:1 ║░
│- Descending│░║ FOT 14 7,168 0.01% 16.0:1 PgDn ║░
│ │░║ SU 14 28,672 0.03% 4.0:1 ║░
└────────────┘░╚═════════════════════════════════════════════════════════════╝░
F1 for Help. PgUp, PgDn, Home, and End to examine statistics. F10 to Exit.
Részletes beszámolót kérhetünk a file-ok tömörítési
arányáról -- itt éppen a kiterjesztés szerinti
áttekintést böngésztünk